The present invention relates generally to protocol analyzers for communication links and more specifically to a device and method for improving the protocol analysis.
Protocol analyzers/emulators are used for installing a communication network, fixing troubles in existing communications networks, improving network performance or developing protocol-oriented products. The protocol analyzer/emulator can monitor a circuit, trace exchanges of commands and responses between network devices, analyze performance or interactively emulate a device. Protocol analyzers/simulators handle complex protocols and interfaces such as T1, ISDN, G.703, SS#7, SDLC, SNA and X.25.
A typical application for a protocol analyzer in public and private networks is illustrated in FIG. 1. Although the end users are shown as computer centers, these may also be telephones or other communication instruments. In the public telephone network the end-users are connected by voice or data lines to the central office (CO). The COs are interconnected by telephone company trunks which are voice and dam lines. The COs are also interconnected by signaling links, possibly using the SS#7 protocol. The major control points in the SS#7 network are signal transfer points (STP's) and service control points (SCPs). Both STP's and SCP's are physically located at the CO's. STPs are interconnected to each other and to the SCP's by signaling links. The protocol analyzer may be connected to any of the data, voice, or signalling links to perform monitoring as well as emulation.
Protocol analyzers analyze communication links between two instruments during the connection, data transfer and disconnection portions of communication. This communication uses specific rules known as a protocol. The protocol includes rules governing successful connection, identification, information exchange, error recovery and disconnection. This information is contained in message units called "frames". Depending upon the system, the network control information is on a common line with dam signal units and/or voice; or on a separate control or signaling link. A primary task of a protocol analyzer is to divide every meaningful frame into parameters or fields and present it as decoded information to the operator.
To prevent the operator from being swamped with all this information, protocol analyzers have filters to select and display preselected information. In the standard approach to filtering, the user would be able to specify a particular message type (for example, "reset circuit" or "call progress"), or address, or release cause (examples: "call rejected" or "destination out of order"), and filter for these messages/addresses/causes exclusively. A frame would only be displayed if it matched the selected message type or address or cause. Thus, the user must know the specific event that he is looking for in order to have the protocol analyzer selectively display the information.
In addition, the protocol analyzer might provide a screen for the values of counters wherein each counter counts each possible message type. Another screen might be filled with another set of counters, with each counter representing a particular "release cause."
In the SS#7 protocol, the message type and release cause would be the first two fields (and quite possibly the only two fields) that a protocol analyzer would be likely to support with filters and counters. The message type and release cause fields are only two fields out of over 500 protocol fields in SS#7, any one of which is potentially important to the success of a particular call setup, or to the health of the signalling link in general.
Most troublesome problems are intermittent. The operator has no pre-warning such that they can count the values of a particular field, or to filter for a particular value. Once a problem occurs during the operation of a system, the operator must visually search through all the display data, looking for any event that is out of the ordinary.
Also, to design appropriate filters to detect specific messages, message types or fields of interest, requires a knowledge of the specific protocol being monitored. Some operators may not be as familiar as others with the protocol therefore they may not be able to design an appropriate filter to detect problems. Thus, the infrequent event concept brings potential problems to the attention of the operator. Once the operator has been made aware of a problem, he can then investigate the problem and determine whether it is appropriate or inappropriate within the protocol being used.
Thus it is an object of the present invention, to provide a protocol analyzer which is capable of detecting infrequent frame events.
Another object of the present invention is to provide a protocol analyzer which keeps a count of every value in every field and reports events on the basis of infrequency.
A further object of the present invention is to provide a protocol analyzer which detects the occurrence of values of a plurality of fields of the communication frame as an infrequent event.
An even further object of the present invention is to provide a protocol analyzer which detects as an infrequent event the occurrence of sequence of pairs of communication frames.
A still even further object of the present invention is to provide a protocol analyzer which detects as an infrequent event the occurrence of ranges of time periods between pairs of communication frames.
These and other objects are achieved by identifying frame events of communication frames from a communication link, and determining which frame events have an occurrence below a preselected frequency. The results are displayed. The frame events having an occurrence below the preselected frequency are determined by counting the occurrence of each type of frame event for a preselected period. This count is compared against a count of the preselected periods. If the counted occurrences are below the count of the preselected periods, this determines a frame event having an occurrence below the preselected frequency.
The communication frames have a plurality of data fields and the frame event is the occurrence of each value of the dam field, which is counted. In another embodiment, the frame event may be the occurrence of a sequence of pairs of communications frames. Thus each specific sequence of previous and current message types or frames is counted and compared with the period count. In another embodiment, the frame event is the occurrence of time periods between pairs of communication frames. The lapsed time between specific sequences of frames is counted as belonging to a particular time range and compared with the period count.
The protocol analyzer is capable of receiving and storing communication frames for offline analysis and may be connected to a communication link and perform real time identification. The protocol analyzer is portable and operable in any mode.
Other objectives, advantages and novel features of the present invention will become apparent from the following detailed description of the invention when considered in conjunction with the accompanying drawings.